User-Centred Requirements Handbook |
The prototype is tested with users and observations recorded by evaluators. Also performance scores and subjective ratings are recorded which may be used as a basis for a user requirements test plan.
Process - Present to Users and Gather Feedback
The prototype can be presented to users as part of a discussion session. By 'walking through' specific system tasks (e.g. the task scenarios), the user can provide feedback on the design approach leading to changes being made where appropriate.
More formally, the system is demonstrated to users by talking through each of the system tasks. The walkthrough may be conducted using the concept description whether it is represented on paper or as a prototype. Guidelines for conducting a walkthrough are given in Part C (section 4.18).
The basic approach is to for the evaluator and the user(s) to select a range of suitable task scenarios (from those listed in section 2.3). They then discuss how each task would be carried out, with the new system, in a step-by-step fashion.
The task walkthrough will serve to validate the system concepts and identify parts that require change. For a particular task, the different interactions required between the user and the system, or with other people, will also become clearer and specified in more detail. Further details such as task frequency, duration and criticality will also emerge leading to improved system navigation, warnings, confirmation dialogues, etc. The task walkthrough results may be recorded using a form similar to that shown below (Form 2.6).
The following steps provide a guide for running walkthrough sessions.
1. Decide what issues or task scenarios should be covered by the walkthrough.
2. Set up a recording mechanism to gather user comments. This may be for one person to show the system and ask questions, with another person taking notes or recording the discussion on tape for transcription later.
3. Select appropriate users to take part in the walkthrough, trying to cover the range of user groups within the target population. Other stakeholders with an interest in how the system will operate such as supervisors and maintenance staff may also wish to be included within the walkthrough. Similarly stakeholders interested in the system generally or are affected by its outputs (e.g. managers and customers) may wish to view and comment on the system but at a higher level of detail.
4. Pilot the walkthrough to work out how much time is needed for each session.
5. Ensure recording facilities are available and working properly.
6. Conduct the walkthrough sessions, making sure that each session covers the issues identified beforehand.
7. Analyse the information obtained grouping them appropriately. Rather than group them by task, it may be preferable to group them according to the nature of the issue e.g. task match, screen layout, user support etc. Try to determine how many users made the same comment and assign frequency values to them. Consider the importance of the problems identified as a result of the comments and list them in order of priority.
Form 2.6- Task Walkthrough Feedback (example)
| 2.6 Task walkthrough feedback | |||
| System: Bank machine | |||
| User group: User group | |||
| Transferred from Form 2.3 Task scenarios. | |||
| Task scenario | Comments | Modified or New System Requirement | Ref. |
|
S7(4) The user inserts the card without looking at it. It is not accepted by the machine, so the user reorients it and reinserts it. The user forgets the PIN, and tries several attempts. The machine keeps the card. |
Picture on machine helped user to re-orientate the card. Machine keeping card seems unsatisfactory. User prefers card to be returned to allow them to test it at the bank. |
If user forgets PIN, system returns card for user to take into bank. If card not shown to bank within 5 days, it is cancelled and letter sent to customer with new card. |
2.6.1 |
|
S8(4) The user inserts the card and enters their PIN. They request £100. They receive a receipt but an incorrect amount of money. |
Users want a way to notify the bank that a fault has occurred immediately so the bank can check back whether enough money has been located. | If an incorrect amount of money has been dispensed, the user presses a special button to allow them to report the fault by video camera at the machine. | 2.6.2 |
Copy to relevant Stage 3
Forms.